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Abstract 


Network operators require NAT devices to log events like creation and 
deletion of translations and information about the resources that the 
NAT device is managing. In many cases, the logs are essential to 
identify an attacker or a host that was used to launch malicious 
attacks and for various other purposes of accounting. Since there is 
no standard way of logging this information, different NAT devices 
use proprietary formats; hence, it is difficult to expect consistent 
behavior. This lack of standardization makes it difficult to write 
the Collector applications that would receive this data and process 
it to present useful information. This document describes the 
formats for logging NAT events. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8158. 
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1. Introduction 


The IP Flow Information Export (IPFIX) Protocol [RFC7011] defines a 
generic push mechanism for exporting information and events. The 
IPFIX Information Model [IPFIX-IANA] defines a set of standard 
Information Elements (IEs) that can be carried by the IPFIX protocol. 
This document details the IPFIX IEs that MUST be logged by a NAT 
device that supports NAT logging using IPFIX and all the optional 
fields. The fields specified in this document are gleaned from 
[RFC4787] and [RFC5382]. 


This document and [NAT-LOG] are written in order to standardize the 
events and parameters to be recorded using IPFIX [RFC7011] and SYSLOG 
[RFC5424], respectively. This document uses IPFIX as the encoding 
mechanism to describe the logging of NAT events. However, the 
information that is logged should be the same irrespective of what 
kind of encoding scheme is used. IPFIX is chosen because it is an 
IETF standard that meets all the needs for a reliable logging 
mechanism. IPFIX provides the flexibility to the logging device to 
define the datasets that it is logging. The IEs specified for 
logging must be the same irrespective of the encoding mechanism used. 


1.1. Terminology 


The term "NAT device" in this document refers to any NAT44 or NAT64 
device. The term "Collector" refers to any device that receives 
binary data from a NAT device and converts it into meaningful 
information. This document uses the term "session" as defined in 
[RFC2663], and the term "Binding Information Base" (BIB) as defined 
in [RFC6146]. The term "Information Element" or "IE" is defined in 
[RFC7011]. The term "Carrier-—Grade NAT" refers to a large-scale NAT 
device as described in [RFC6888] 


The IPFIX IEs that are NAT specific are created with NAT terminology. 
In order to avoid creating duplicates, IES are reused if they convey 
the same meaning. This document uses the term "timestamp" for the 
IE, which defines the time when an event is logged; this is the same 
as the IPFIX term "observationTimeMilliseconds" as described in 
[IPFIX-IANA]. Since observationTimeMilliseconds is not self- 
explanatory for NAT implementors, the term "timeStamp" is used. 

Event templates, which refer to IPFIX Template Records, as well as 
log events, which refer to IPFIX Flow Records, are also used in this 
document. 
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1.2. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


2. Scope 


This document provides the information model to be used for logging 


the NAT events, including Carrier-Grade NAT (CGN) events. [RFC7011] 
provides guidance on the choices of the transport protocols used for 
IPFIX and their effects. This document does not provide guidance on 


transport protocols like TCP, UDP, or Stream Control Transmission 
Protocol (SCTP), which are to be used to log NAT events. The logs 
SHOULD be reliably sent to the Collector to ensure that the log 
events are not lost. The choice of the actual transport protocol is 
beyond the scope of this document. 


This document uses the allocated IPFIX IEs in the IANA "IPFIX 
Information Elements" registry [IPFIX-IANA] and registers some new 
ones. 


This document assumes that the NAT device will use the existing IPFIX 
framework to send the log events to the Collector. This would mean 
that the NAT device will specify the template that it is going to use 
for each of the events. The templates can be of varying length, and 
there could be multiple templates that a NAT device could use to log 
the events. 


The implementation details of the Collector application are beyond 
the scope of this document. 


The optimization of logging the NAT events is left to the 
implementation and is beyond the scope of this document. 


3. Deployment 


NAT logging based on IPFIX uses binary encoding; hence, it is very 
efficient. IPFIX-based logging is recommended for environments where 
a high volume of logging is required, for example, where per-flow 
logging is needed or in case of Carrier-Grade NAT. However, IPFIX- 
based logging requires a Collector that processes the binary data and 
requires a network management application that converts this binary 
data to a human-readable format. 
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A Collector may receive NAT events from multiple CGN devices. The 
Collector distinguishes between the devices using the source IP 
address, source port, and Observation Domain ID in the IPFIX header. 
The Collector can decide to store the information based on the 
administrative policies that are in line with the operator and the 
local jurisdiction. The retention policy is not dictated by the 
Exporter and is left to the policies that are defined at the 
Collector. 


A Collector may have scale issues if it is overloaded by a large 
number of simultaneous events. An appropriate throttling mechanism 
may be used to handle the oversubscription. 


The logs that are exported can be used for a variety of reasons. An 
example use case is to do accounting based on when the users logged 
on and off. The translation will be installed when the user logs on 
and removed when the user logs off. These events create log records. 
Another use case is to identify an attacker or a host in a provider 
network. The network administrators can use these logs to identify 
the usage patterns, the need for additional IP addresses, and etc. 
The deployment of NAT logging is not limited to just these cases. 


4. Event-Based Logging 


An event in a NAT device can be viewed as a state transition because 
it relates to the management of NAT resources. The creation and 
deletion of NAT sessions and bindings are examples of events, as they 
result in resources (addresses and ports) being allocated or freed. 
The events can happen through the processing of data packets flowing 
through the NAT device, through an external entity installing 
policies on the NAT router, or as a result of an asynchronous event 
like a timer. The list of events is provided in Table 2. Each of 
these events SHOULD be logged, unless this is administratively 
prohibited. A NAT device MAY log these events to multiple Collectors 
if redundancy is required. The network administrator will specify 
the Collectors to which the log records are to be sent. It is 
necessary to preserve the list of Collectors and its associated 
information like the IPv4/IPv6 address, port, and protocol across 
reboots so that the configuration information is not lost when the 
device is restarted. The NAT device implementing the IPFIX logging 
MUST follow the IPFIX specification in [RFC7011]. 


4.1. Logging Destination Information 


Logging destination information in a NAT event is discussed in 


[RFC6302] and [RFC6888]. Logging destination information increases 
the size of each record and increases the need for storage 
considerably. It increases the number of log events generated 
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because when the same user connects to a different destination, it 
results in a log record per destination address. Logging the source 
and destination addresses results in loss of privacy. Logging of 
destination addresses and ports, pre- or post-NAT, SHOULD NOT be done 
[RFC6888]. However, this document provides the necessary fields to 
log the destination information in cases where they must be logged. 


a2 s Information Elements 


The templates could contain a subset of the IEs shown in Table 1, 
depending upon the event being logged. For example, a NAT44 session 
creation template record will contain: 


{sourceIPv4Address, postNATSourcelIPv4Address, destinationIPv4Address, 
postNATDestinationIPv4Address, sourceTransportPort, 
postNAPTSourceTransportPort, destinationTransportPort, 
postNAPTDestinationTransportPort, internalAddressRealm, natEvent, 
timeStamp} 


An example of the actual event data record is shown below in a human- 
readable form: 


{192.0.2.1, 203.0.113.100, 192.0.2.104, 192.0.2.104, 14800, 1024, 80, 
80, 0, 1, 09:20:10:789} 


A single NAT device could be exporting multiple templates, and the 
Collector MUST support receiving multiple templates from the same 
source. 
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The following table includes all the IEs that a NAT device would need 
to export the events. The formats of the IEs and the IPFIX IDs are 
listed. Detailed descriptions of the fields natInstancelID, 
rnalAddressRealm, natQuotaExceededEvent, 
and natThresholdEvent are included in the IANA Considerations 


internalAddressRealm, exte 
section. 


+ Pe a Fore ae ae a Oy a (ye Be Ye ee ee aR 
Field Name 


timeStamp 


natInstanceID 


vianiId 


ingressVRFID 


postNATSourcelIPv4Address 


protocollIdentifier 


sourceTransportPort 


postNAPTSourceTransportP 


| 

| 

| 

| 

| 

| 

| 

| 

| 

| sourceIPv4Address 
| 

| 

| 

| 

| 

| 

| 

| 

| destinationIPv4Address 
| 
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tea a Nn a as Seat pt +-------—- 


32 


16 


32 


32 


32 


ort 16 


32 


i +} 


Standards Track 


+ 


a +} 


58 


234 


225 


227 


12 


+ 


ag a gaap Ce pinh YOR) (aE pap Pai gee rn YR + 
Description 
bees I 
System Time 
when the 

event 

occurred 


NAT Instance 
Identifier 


VLAN ID in 
case of 
overlapping 
networks 


VRF ID in 
case of 
overlapping 
networks 


Address 
Translated 
Source IPv4 


Address 


Transport 
protocol 


Source Port 


Translated 
Source port 


Destination 
IPv4 Address 


| 
| 
| 
| 
| 
| 
| 
| 
| 
Source IPv4 | 
| 
| 
| 
| 
| 
| 
| 
| 
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postNATDestinationIPv4Address 


destinationTransportPort 


postNAPTDestinationTransportPort 


sourceIPv6Address 


destinationIPv6éAddress 


postNATSourcelIPvéAddress 


postNATDestinationIPvé6éAddress 


internalAddressRealm 


externalAddressRealm 


natEvent 


portRangeStart 


portRangeEnd 


natPoollId 


Standards 


32 


16 


16 


128 


128 


128 


128 


16 


16 


32 


Track 


IPFIX IEs for NAT Logging 


226 


Ad. 


228 


27 


28 


281 


282 


464 


230 


283 
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Translated 
IPv4 
destination 
address 


Destination 
port 


Translated 
Destination 
port 


Source IPv6 
address 


Destination 
IPv6 address 


Translated 
source IPv6 
address 


Translated 
Destination 
IPv6 address 


Source 
Address 
Realm 


Destination 
Address 
Realm 


Type of 
Event 


Allocated 
port block 
start 


Allocated 
Port block 
end 


NAT pool 
Identifier 
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natQuotaExceededEvent 


natThresholdEvent 


maxSessionEntries 


maxBIBEntries 


maxEntriesPerUser 


maxSubscribers 


addressPoolHighThreshold 


addressPoolLowThreshold 


addressPortMappingHighTh 
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maxFragmentsPendingReassembly 


reshold 


addressPortMappingLowThreshold 


Standards 


32 


32 


32 


32 


32 


32 


32 


32 


32 


32 


32 
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466 


467 


471 


472 


473 


474 


476 


477 


478 


479 
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Limit event 
identifier 


Threshold 
event 
identifier 


Maximum 
session 
entries 


Maximum bind 
entries 


Maximum 
entries per- 
user 


Maximum 
subscribers 


Maximum 
fragments 
for 
ressembly 


High 
threshold 
for address 
pool 


Low 
threshold 
for address 
pool 


High 
threshold 
for 
address/port 
mapping 


Low 
threshold 
for 
address/port 
mapping 
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480 High | 
threshold | 
for per-user 
address/port 


mapping 


addressPortMappingPerUserHighThre 
shold 


| 

| | 
| | 
481 | High | 
| threshold | 
for global 
address 

| | 
+ 


mapping 


| 
| 
| 
| 
| 
+ 


Note: (*) indicates octetArray 
Table 1: NAT IE List 
4.3. Definition of NAT Events 


The following is the complete list of NAT events and the proposed 
event type values. The natEvent IE is defined in the "IPFIX 
Information Elements" registry [IPFIX-IANA];. The list can be 
expanded in the future as necessary. The data record will have the 
corresponding natEvent value to indicate the event that is being 
logged. 


Note that the first two events are marked "Historic" and are listed 
here for the sole purpose of completeness. Any compliant 
implementation SHOULD NOT use the events that are marked "Historic". 
These values were defined prior to the existence of this document and 
outside the IETF. These events are not standalone and require more 
information to be conveyed to qualify the event. For example, the 
NAT translation create event does not specify if it is NAT44 or 
NAT64. As a result, the Behave working group decided to have an 
explicit definition for each one of the unique events. 
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+------- $------------------------------------ + 
| Value | Event Name | 
+------- 4------------------------------------ + 
| o | Reserved | 
|1 | NAT translation create (Historic) | 
| 2 | NAT translation delete (Historic) | 
| 3 | NAT Addresses exhausted | 
| 4 | NAT44 session create | 
| 5 | NAT44 session delete | 
6 NAT64 session create 
|7 | NAT64 session delete | 
| 8 | NAT44 BIB create | 
| 9 | NAT44 BIB delete | 
| 10 | NAT64 BIB create | 
| 11 | NAT64 BIB delete | 
| 12 | NAT ports exhausted | 
13 Quota Exceeded 
| 14 | Address binding create | 
|15 | Address binding delete | 
| 16 | Port block allocation 
| 17 | Port block de-allocation 
| 18 | Threshold Reached 
+------- $------------------------------------ + 
Table 2: NAT Event ID 
4.4. Quota Exceeded Event Types 
The Quota Exceeded event is a natEvent IE described in Table 2. The 


Quota Exceeded events are generated when the hard limits set by the 
administrator have been reached or exceeded. The following table 
shows the sub-event types for the Quota Exceeded event. The events 
that can be reported are the maximum session entries limit reached, 
maximum BIB entries limit reached, maximum (session/BIB) entries per 
user limit reached, maximum active hosts or subscribers limit 
reached, and maximum Fragments pending reassembly limit reached. 
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SS ar es ae Same a a are ae Saar a eee te ae ae ae a es a eg et + 
Quota Exceeded Event Name | 


Reserved | 
Maximum session entries 

Maximum BIB entries 

Maximum entries per user | 
Maximum active hosts or subscribers | 
Maximum fragments pending reassembly | 


+ ——— + 


Table 3: Quota Exceeded Event 
4.5. Threshold Reached Event Types 


The following table shows the sub-event types for the Threshold 
Reached event. The administrator can configure the thresholds, and 
whenever the threshold is reached or exceeded, the corresponding 
events are generated. The main difference between the Quota Exceeded 
and Threshold Reached events is that, once the Quota Exceeded events 
are hit, the packets are dropped or mappings will not be created, 
whereas the Threshold Reached events will provide the operator a 
chance to take action before the traffic disruptions can happen. A 
NAT device can choose to implement one or the other, or both. 


The address pool high threshold event will be reported when the 
address pool reaches a high-water mark as defined by the operator. 
This will serve as an indication that either the operator might have 
to add more addresses to the pool or the subsequent users may be 
denied NAT translation mappings. 


The address pool low threshold event will be reported when the 
address pool reaches a low-water mark as defined by the operator. 
This will serve as an indication that the operator can reclaim some 
of the global IPv4 addresses in the pool. 


The address and port mapping high threshold event is generated when 
the number of ports in the configured address pool has reached a 
configured threshold. 


The per-user address and port mapping high threshold is generated 
when a single user utilizes more address and port mapping than a 
configured threshold. We don’t track the low threshold for per-user 
address and port mappings because, as the ports are freed, the 


address will become available. The address pool low threshold event 
will then be triggered so that the global IPv4 address can be 
reclaimed. 
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The global address mapping high threshold event is generated when the 
maximum number of mappings per user is reached for a NAT device doing 
paired-address pooling. 


l 
| 
| 
l 
| 
| 
l 
| 
| 
| 
l 
| 
l 
l 
l 
l 
| 
l 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
l 
| 
l 
| 
l 
l 
| 
| 
| 
| 
l 
| 
| 
| 
| 
l 
l 
| 
| 
| 
l 
| 
l 
| 
l 
l 
| 
| 
| 
+ 


Threshold Exceeded Event Name 


l 
l 
l 
| 
| 
l 
l 
| 
l 
| 
| 
l 
l 
l 
| 
| 
| 
| 
| 
| 
| 
l 
| 
| 
l 
| 
l 
| 
l 
| 
l 
l 
| 
| 
l 
l 
| 
| 
l 
| 
l 
| 
| 
| 
| 
| 
| 
| 
l 
| 
| 
| 
| 
| 
| 
l 
l 
+ 


Reserved 

Address pool high threshold event 

Address pool low threshold event 

Address and port mapping high threshold event | 
Address and port mapping per user high threshold event | 
Global address mapping high threshold event | 


+ ——— ++ — + 


| 
| 
| 
| 
l 
| 
l 
l 
| 
| 
l 
| 
l 
l 
l 
| 
| 
| 
| 
| 
l 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
l 
| 
l 
| 
| 
l 
| 
l 
l 
l 
l 
| 
l 
l 
l 
| 
| 
| 
| 
| 
| 
l 
| 
| 
| 
| 
+ 


Table 4: Threshold Event 
4.6. Templates for NAT Events 


The following is the template of events that will be logged. The 
events below are identified at the time of this writing, but the set 
of events is extensible. A NAT device that implements a given NAT 
event MUST support the mandatory IEs in the templates. Depending on 
the implementation and configuration, various IEs that are not 
mandatory can be included or ignored. 


4.6.1. NAT44 Session Create and Delete Events 


These events will be generated when a NAT44 session is created or 
deleted. The template will be the same; the natEvent will indicate 
whether it is a create or a delete event. The following is a 
template of the event. 


The destination address and port information is optional as required 
by [RFC6888]. However, when the destination information is 
suppressed, the session log event contains the same information as 
the BIB event. In such cases, the NAT device SHOULD NOT send both 
BIB and session events. 
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eee ne ee ne gee ae eee ee ene ee toss 

| Field Name | Size (bits) 

tr toss saa 

| timeStamp | 64 

| natEvent | 8 

| sourceIPv4Address | 32 

| postNATSourceIPv4Address | 32 

| protocolIdentifier | 8 

| sourceTransportPort | 16 
postNAPTSourceTransportPort 16 

| destinationIPv4Address | 32 

| postNATDestinationIPv4Address | 32 

| destinationTransportPort | 16 

| postNAPTDestinationTransportPort | 16 

| natInstanceID | 32 

| vlanID/ingressVRFID | 16/32 
internalAddressRealm octetArray 

| externalAddressRealm | octetArray 

Spat estan pine eee E AA a eT ca aa ea etre: 


+ 
| 
+ 
| 
| 
| 
| 
| 
| 
| 
| 
| 

+ 
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Sat + 
Mandatory | 


Table 5: NAT44 Session Delete/Create Template 


4.6.2. NAT64 Session Create and Delete Events 


These events will be generated when a NAT64 session is created or 


deleted. The following is a template of the event. 


ssi eta aca a a a IR paan treina + 
| Field Name | Size (bits) | Mandatory | 
a EEAS EAE A E + 
| timestamp | 64 | Yes | 
| natEvent | 8 | Yes | 
| sourceIPv6Address | 128 | Yes 
| postNATSourcelIPv4Address | 32 | Yes | 
protocolliIdentifier 8 Yes 
| sourceTransportPort | 16 | Yes | 
| postNAPTSourceTransportPort | 16 | Yes 
| destinationIPv6Address | 128 | No 
| postNATDestinationIPv4Address | 32 | No 
| destinationTransportPort | 16 | No | 
postNAPTDestinationTransportPort 16 No 
| natInstanceID | 32 | No | 
| vlanID/ingressVRFID | 16/32 | No 
| internalAddressRealm | octetArray | No 
| externalAddressRealm | octetArray | No 
PSSSsSSSSSSas Sess SS SSS SSS SS SSSs EEE to--- 5777-7 + 
Table 6: NAT64 Session Create/Delete Event Template 
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4.6.3. NAT44 BIB Create and Delete Events 


These events will be generated when a NAT44 Bind entry is created or 
deleted. The following is a template of the event. 


te a ee pes D StS eee pama Ena + 

| Field Name | Size (bits) | Mandatory | 

PESE a a EN EEEE + 
timeStamp 64 Yes 
natEvent 8 Yes 

| sourceIPv4Address | 32 | Yes | 

| postNATSourceIPv4Address | 32 | Yes 

| protocolIdentifier | 8 | No | 

| sourceTransportPort | 16 | No | 

| postNAPTSourceTransportPort | 16 | No 
natInstanceID 32 No 

| vlanID/ingressVRFID | 16/32 | No | 

| internalAddressRealm | octetArray | No 

| externalAddressRealm | octetArray | No 

te Sess ses ase SSe Ss SSS FSS S555 5 HeSSseH=SSSSss= pesien SSS + 


Table 7: NAT44 BIB Create/Delete Event Template 
4.6.4. NAT64 BIB Create and Delete Events 


These events will be generated when a NAT64 Bind entry is created or 
deleted. The following is a template of the event. 


aca oa cS cm soa Tenga 7-7-7 + 
| Field Name | Size (bits) | Mandatory | 
5 ac aaa a aa aetna E to- soa to--- 777-77 + 
| timeStamp | 64 | Yes | 
| natEvent | 8 | Yes | 
| sourcelIPv6Address | 128 | Yes | 
postNATSourcelIPv4Address 32 Yes 
| protocoliIdentifier | 8 | No | 
| sourceTransportPort | 16 | No | 
| postNAPTSourceTransportPort | 16 | No 
| natInstanceID | 32 | No | 
| vlanID/ingressVRFID | 16/32 | No | 
internalAddressRealm octetArray No 
| externalAddressRealm | octetArray | No 
ee eg ee E E p eer ae poiran + 


Table 8: NAT64 BIB Create/Delete Event Template 
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4.6.5. Addresses Exhausted Event 


This event will be generated when a NAT device runs out of global 
IPv4 addresses in a given pool of addresses. Typically, this event 
would mean that the NAT device won’t be able to create any new 
translations until some addresses/ports are freed. This event SHOULD 
be rate-limited, as many packets hitting the device at the same time 
will trigger a burst of addresses exhausted events. 


The following is a template of the event. 


+--------------- +------------- +----------- + 

| Field Name | Size (bits) | Mandatory | 

+--------------- +------------- +----------- + 

| timeStamp | 64 | Yes | 
natEvent 8 Yes 
natPoolID 32 Yes 

| natInstanceID | 32 | No 

+--------------- +------------- +----------- + 


Table 9: Addresses Exhausted Event Template 
4.6.6. Ports Exhausted Event 


This event will be generated when a NAT device runs out of ports for 
a global IPv4 address. Port exhaustion shall be reported per 
protocol (UDP, TCP, etc.). This event SHOULD be rate-limited, as 
many packets hitting the device at the same time will trigger a burst 
of port exhausted events. 


The following is a template of the event. 


+-------------------------- +------------- +----------- + 
| Field Name | Size (bits) | Mandatory | 
$-------------------------- +------------- +----------- + 
| timeStamp | 64 | Yes 
| natEvent | 8 | Yes | 
| postNATSourceIPv4Address | 32 | Yes 
| protocolIdentifier | 8 | Yes 
| natInstanceID | 32 | No | 
+-------------------------- +------------- +----------- + 


Table 10: Ports Exhausted Event Template 
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4.6.7. Quota Exceeded Events 


This event will be generated when a NAT device cannot allocate 
resources as a result of an administratively defined policy. The 
Quota Exceeded event templates are described below. 


4.6.7.1. Maximum Session Entries Exceeded 
The maximum session entries exceeded event is generated when the 


administratively configured NAT session limit is reached. The 
following is the template of the event. 


Forana ---------- 4-—------------ EEEE + 

| Field Name | Size (bits) | Mandatory | 

E E E Terren aSr an +----------- + 
timeStamp 64 Yes 
natEvent 8 Yes 

| natQuotaExceededEvent | 32 | Yes 

| maxSessionEntries | 32 | Yes 

| natInstanceID | 32 | No | 

fe ee RE EEA E AE E E + 


Table 11: Session Entries Exceeded Event Template 
4.6.7.2. Maximum BIB Entries Exceeded 
The maximum BIB entries exceeded event is generated when the 


administratively configured BIB entry limit is reached. The 
following is the template of the event. 


E +------------- 4+----------- + 

| Field Name | Size (bits) | Mandatory | 

R 4+------------- 4+----------- + 
timeStamp 64 Yes 
natEvent 8 Yes 

| natQuotaExceededEvent | 32 | Yes 

| maxBIBEntries | 32 | Yes | 

| natInstanceID | 32 | No | 

a Sain a soe E asa +------------- oo SSS + 


Table 12: BIB Entries Exceeded Event Template 
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4.6.7.3. Maximum Entries per User Exceeded 


This event is generated when a single user reaches the 
administratively configured NAT translation limit. The following is 
the template of the event. 


$----------------------- +------------- +--------------- + 
| Field Name | Size (bits) | Mandatory | 
$----------------------- +------------- +--------------- + 
| timeStamp | 64 | Yes | 
| natEvent | 8 | Yes | 
| natQuotaExceededEvent | 32 | Yes 
| maxEntriesPerUser | 32 | Yes 
| sourceIPv4Address | 32 | Yes for NAT44 | 
| sourceIPv6Address | 128 | Yes for NAT64 | 
natInstanceID 32 No 
vlanID/ingressVRFID 16/32 No 
$----------------------- +------------- +--------------- + 


Table 13: Per-User Entries Exceeded Event Template 
4.6.7.4. Maximum Active Hosts or Subscribers Exceeded 
This event is generated when the number of allowed hosts or 


subscribers reaches the administratively configured limit. The 
following is the template of the event. 


E a tana cm cmtamiacoaic a E E Seana eae + 
| Field Name | Size (bits) | Mandatory | 
4----------------------- 4+------------- 4+----------- + 
| timeStamp | 64 | Yes | 
| natEvent | 8 | Yes | 
| natQuotaExceededEvent | 32 | Yes 
maxSubscribers 32 Yes 
natInstanceID 32 No 
E ee E ea | pean arene tae aes + 


Table 14: Maximum Hosts/Subscribers Exceeded Event Template 
4.6.7.5. Maximum Fragments Pending Reassembly Exceeded 


This event is generated when the number of fragments pending 
reassembly reaches the administratively configured limit. Note that 
in the case of NAT64, when this condition is detected in the IPv6-to- 
IPv4 direction, the IPv6 source address is mandatory in the template. 
Similarly, when this condition is detected in IPv4-to-IPv6 direction, 
the source IPv4 address is mandatory in the template below. The 
following is the template of the event. 
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aS ea SSeS ane Seas ee eae E ate ce as t--- 55-55-55 + 

| Field Name | Size (bits) | Mandatory | 

toa 5-5 = Pee a S + 

| timeStamp | 64 | Yes 

| natEvent | 8 | Yes | 

| natQuotaExceededEvent | 32 | Yes 

| maxFragmentsPendingReassembly | 32 | Yes 

| sourceIPv4Address | 32 | Yes for NAT44 | 
sourceIPv6Address 128 Yes for NAT64 
natInstanceID 32 No 

| vlanID/ingressVRFID | 16/32 | No 

| internalAddressRealm | octetArray | No 

toa - 5-5 5 == A E phinnt + 


Table 15: Maximum Fragments Pending Reassembly Exceeded Event 
Template 


4.6.8. Threshold Reached Events 


This event will be generated when a NAT device reaches an operator- 
configured threshold when allocating resources. The Threshold 
Reached events are described in the section above. The following is 
a template of the individual events. 


4.6.8.1. Address Pool High or Low Threshold Reached 
This event is generated when the high or low threshold is reached for 


the address pool. The template is the same for both high and low 
threshold events 


e a E 5-5-5555 4+-------- 4+----------- + 
| Field Name | Size | Mandatory | 
| | (bits) | | 
poteren aE E 5-5-5 = 4+-------- 4+----------- + 
| timeStamp | 64 | Yes | 
| natEvent | 8 | Yes | 
| natThresholdEvent | 32 | Yes 
| natPoolID | 32 | Yes | 
| addressPoolHighThreshold/ | 32 | Yes | 
addressPoolLowThreshold 
natInstanceID 32 No 
A E = +-------- 4+----------- + 


Table 16: Address Pool High/Low Threshold Reached Event Template 
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4.6.8.2. Address and Port Mapping High Threshold Reached 


December 2017 


This event is generated when the high threshold is reached for the 


address pool and ports. 


+ Sa Sep Sat: sag Med pel pas ome > Rl, cl eo alt fm, seed ee eg ie) el bt eee Send Se Pt a, nl oe Yt em Sa Se Pn E mp fas oe an es Pa a, Se pe: 
| Field Name 


| timeStamp 

| natEvent 

| natThresholdEvent 

| addressPortMappingHighThreshold/ 
| addressPortMappingLowThreshold 

| natInstanceID 


+ ——— + —— + 


+ ——— tt 


E ee + 
Mandatory | 


Table 17: Address Port High Threshold Reached Event Template 


4.6.8.3. Address and Port Mapping per User High Threshold Reached 


This event is generated when the high threshold is reached for the 


per-user address pool and ports. 


+ Asega a a a a fe a a a G a a a E a a ee ey 
| Field Name 


| timeStamp 

| natEvent 

| natThresholdEvent 

| addressPortMappingHighThreshold/ 

| addressPortMappingLowThreshold 
sourceIPv4Address 


sourceIPv6Address 


| 

| 

| natInstanceID 

| vlanID/ingressVRFID 


+ 
| 
| 

+ 
| 
| 
| 
| 
| 
| 
| 
| 
+ 


+ 
| 
| 

+ 
| 
| 
| 
| 
| 
| 
| 
| 
+ 


Sa + 
Mandatory | 


Table 18: Address and Port Mapping per User High Threshold Reached 


Event Template 
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4.6.8.4. Global Address Mapping High Threshold Reached 


This event is generated when the high threshold is reached for the 
per-user address pool and ports. This is generated only by NAT 
devices that use a paired-address-—pooling behavior. 


4----------------------------------- 4------------- 4+----------- + 
| Field Name | Size (bits) | Mandatory | 
4----------------------------------- 4------------- 4+----------- + 
| timeStamp | 64 | Yes 

| natEvent | 8 | Yes | 
| natThresholdEvent | 32 | Yes | 
| globalAddressMappingHighThreshold | 32 | Yes 

| natInstanceID | 32 | No | 
| vlanID/ingressVRFID | 16/32 | No 

4----------------------------------- 4------------- 4+----------- + 


Table 19: Global Address Mapping High Threshold Reached Event 
Template 


4.6.9. Address Binding Create and Delete Events 


These events will be generated when a NAT device binds a local 
address with a global address and when the global address is freed. 
A NAT device will generate the binding events when it receives the 
first packet of the first flow from a host in the private realm. 


+-------------------------- +------------- +--------------- + 
| Field Name | Size (bits) | Mandatory | 
+-------------------------- +------------- +--------------- + 
| timestamp | 64 | Yes | 
| natEvent | 8 | Yes | 
| sourceIPv4Address | 32 | Yes for NAT44 | 
sourceIPv6Address 128 Yes for NAT64 
postNATSourceIPv4Address 32 Yes 
| natInstanceID | 32 | No | 
+-------------------------- +------------- +--------------- + 


Table 20: NAT Address Binding Template 
4.6.10. Port Block Allocation and De-allocation 
This event will be generated when a NAT device allocates/de-allocates 


ports in a bulk fashion, as opposed to allocating a port on a per- 
flow basis. 
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5; 


Ss 


portRangeStart represents the starting value of the range. 
portRangeEnd represents the ending value of the range. 


NAT devices would do this in order to reduce logs and to potentially 
limit the number of connections a subscriber is allowed to use. In 

the following Port Block allocation template, the portRangeStart and 
portRangeEnd MUST be specified. 


It is up to the implementation to choose to consolidate log records 
in case two consecutive port ranges for the same user are allocated 
or freed. 


+-------------------------- +------------- +--------------- + 
| Field Name | Size (bits) | Mandatory | 
+-------------------------- +------------- +--------------- + 
| timeStamp | 64 | Yes | 
| natEvent | 8 | Yes | 
| sourceIPv4Address | 32 | Yes for NAT44 | 
| sourceIPv6Address | 128 | Yes for NAT64 | 
| postNATSourceIPv4Address | 32 | Yes 
portRangeStart 16 Yes 
portRangeEnd 16 No 
| natInstanceID | 32 | No | 
+-------------------------- +------------- +--------------- + 


Table 21: NAT Port Block Allocation Event Template 
Management Considerations 


This section considers requirements for management of the log system 
to support logging of the events described above. It first covers 
requirements applicable to log management in general. Any additional 
standardization required to fulfill these requirements is out of 


scope of the present document. Some management considerations are 
covered in [NAT-LOG]. This document covers the additional 
considerations. 


1. Ability to Collect Events from Multiple NAT Devices 


An IPFIX Collector MUST be able to collect events from multiple NAT 
devices and decipher events based on the Observation Domain ID in the 
IPFIX header. 


Sivakumar & Penno Standards Track [Page 23] 


RFC 8158 IPFIX IEs for NAT Logging December 2017 


5 


6. 


6. 


6. 


-2. Ability to Suppress Events 


The exhaustion events can be overwhelming during traffic bursts; 
hence, they SHOULD be handled by the NAT devices to rate-limit them 
before sending them to the Collectors. For example, when the port 
exhaustion happens during bursty conditions, instead of sending a 
port exhaustion event for every packet, the exhaustion events SHOULD 
be rate-limited by the NAT device. 


IANA Considerations 


sla Information Elements 


IANA has registered the following IEs in the "IPFIX Information 
Elements" registry at [IPFIX-IANA]. 


1.1. natInstanceID 

ElementID: 463 

Name: natInstanceID 

Description: This Information Element uniquely identifies an Instance 
of the NAT that runs on a NAT middlebox function after the packet 
passes the Observation Point. natInstanceID is defined in [RFC7659]. 
Abstract Data Type: unsigned32 

Data Type Semantics: identifier 

Reference: See [RFC791] for the definition of the IPv4 source address 
field. See [RFC3022] for the definition of NAT. See [RFC3234] for 
the definition of middleboxes. 

1.2. internalAddressRealm 

ElementID: 464 

Name: internalAddressRealm 

Description: This Information Element represents the internal address 
realm where the packet is originated from or destined to. By 
definition, a NAT mapping can be created from two address realms, one 
from internal and one from external. Realms are implementation 
dependent and can represent a Virtual Routing and Forwarding (VRF) 
ID, a VLAN ID, or some unique identifier. Realms are optional and, 


when left unspecified, would mean that the external and internal 
realms are the same. 
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Abstract Data Type: octetArray 
Data Type Semantics: identifier 
Reference: See [RFC791] for the definition of the IPv4 source address 
field. See [RFC3022] for the definition of NAT. See [RFC3234] for 
the definition of middleboxes. 

6.1.3. externalAddressRealm 
ElementID: 465 


Name: externalAddressRealm 


Description: This Information Element represents the external address 


realm where the packet is originated from or destined to. The 
detailed definition is in the internal address realm as specified 
above. 


Abstract Data Type: octetArray 
Data Type Semantics: identifier 


Reference: See [RFC791] for the definition of the IPv4 source address 
field. See [RFC3022] for the definition of NAT. See [RFC3234] for 
the definition of middleboxes. 


6.1.4. natQuotaExceededEvent 
ElementID: 466 
Name: natQuotaExceededEvent 


Description: This Information Element identifies the type of a NAT 
Quota Exceeded event. Values for this Information Element are listed 
in the "NAT Quota Exceeded Event Type" registry, see [IPFIX-IANA]. 
Initial values in the registry are defined by the table below. New 
assignments of values will be administered by IANA and are subject to 
Expert Review [RFC8126]. Experts need to check definitions of new 
values for completeness, accuracy, and redundancy. 
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pee er ee a ee a ee er er ee Se ee ee er + 
Quota Exceeded Event Name | 


+ 
| 
+ 
| Reserved | 
| Maximum session entries | 
| Maximum BIB entries | 
| Maximum entries per user | 
| Maximum active hosts or subscribers | 
| Maximum fragments pending reassembly | 
+ 


Note: This is the same as Table 3. 
Abstract Data Type: unsigned32 
Data Type Semantics: identifier 


Reference: See [RFC791] for the definition of the IPv4 source address 
field. See [RFC3022] for the definition of NAT. See [RFC3234] for 
the definition of middleboxes. 


6.1.5. natThresholdEvent 
ElementID: 467 
Name: natThresholdEvent 


Description: This Information Element identifies a type of a NAT 
Threshold event. Values for this Information Element are listed in 
the "NAT Threshold Event Type" registry, see [IPFIX-IANA]. Initial 
values in the registry are defined by the table below. New 
assignments of values will be administered by IANA and are subject to 
Expert Review [RFC8126]. Experts need to check definitions of new 
values for completeness, accuracy, and redundancy. 


Sa a SS ee SS eS SS Se SS eS SS SS SS eS Se eS ee + 

Threshold Exceeded Event Name 

a Sag a en a ean H R oe GH oy + 

Reserved 

Address pool high threshold event 

Address pool low threshold event 

Address and port mapping high threshold event | 
| 


< 

w 

| 

c 

o 
+— + 


Address and port mapping per user high threshold event 
Global address mapping high threshold event 


+ ——_—- 


Note: This is the same as Table 4. 
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Abstract Data Type: unsigned32 
Data Type Semantics: identifier 


Reference: See [RFC791] for the definition of the IPv4 source address 
field. See [RFC3022] for the definition of NAT. See [RFC3234] for 
the definition of middleboxes. 


6.1.6. natEvent 


The original definition of this Information Element specified only 
three values: 1, 2, and 3. This definition has been replaced by a 
registry, to which new values can be added. The semantics of the 
three originally defined values remain unchanged. IANA maintains the 
"NAT Event Type (Value 230)" registry for values of this Information 
Element at [IPFIX-IANA]. 


ElementID: 230 
Name: natEvent 


Description: This Information Element identifies a NAT event. This 
IE identifies the type of a NAT event. Examples of NAT events 
include, but are not limited to, NAT translation create, NAT 
translation delete, Threshold Reached, or Threshold Exceeded, etc. 
Values for this Information Element are listed in the "NAT Event 
Type" registry, see [IPFIX-IANA]. The NAT event values in the 
registry are defined by Table 2 in Section 4.3. New assignments of 
values will be administered by IANA and are subject to Expert Review 
[RFC8126]. Experts need to check definitions of new values for 
completeness, accuracy, and redundancy. 


Abstract Data Type: unsigned8 
Data Type Semantics: identifier 
Reference: See [RFC3022] for the definition of NAT. See [RFC3234] 


for the definition of middleboxes. See RFC 8158 for the definitions 
of values 4-16. 


6.1.7. maxSessionEntries 
ElementID: 471 
Name: maxSessionEntries 


Description: This element represents the maximum session entries that 
can be created by the NAT device. 
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Abstract Data Type: unsigned32 
Data Type Semantics: identifier 


Reference: See [RFC3022] for the definition of NAT. See [RFC3234] 
for the definition of middleboxes. 


6.1.8. maxBIBEntries 
ElementID: 472 


Name: maxBIBEntries 


Description: This element represents the maximum BIB entries that can 
be created by the NAT device. 


Abstract Data Type: unsigned32 
Data Type Semantics: identifier 


Reference: See [RFC3022] for the definition of NAT. See [RFC3234] 
for the definition of middleboxes. 


6.1.9. maxEntriesPerUser 
ElementID: 473 
Name: maxEntriesPerUser 


Description: This element represents the maximum NAT entries that can 
be created per user by the NAT device. 


Abstract Data Type: unsigned32 
Data Type Semantics: identifier 


Reference: See [RFC3022] for the definition of NAT. See [RFC3234] 
for the definition of middleboxes. 


6.1.10. maxSubscribers 
ElementID: 474 
Name: maxSubscribers 


Description: This element represents the maximum subscribers or 
maximum hosts that are allowed by the NAT device. 
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Abstract Data Type: unsigned32 
Data Type Semantics: identifier 


Reference: See [RFC3022] for the definition of NAT. See [RFC3234] 
for the definition of middleboxes. 


6.1.11. maxFragmentsPendingReassembly 
ElementID: 475 
Name: maxFragmentsPendingReassembly 


Description: This element represents the maximum fragments that the 
NAT device can store for reassembling the packet. 


Abstract Data Type: unsigned32 
Data Type Semantics: identifier 


Reference: See [RFC3022] for the definition of NAT. See [RFC3234] 
for the definition of middleboxes. 


6.1.12. addressPoolHighThreshold 
ElementID: 476 
Name: addressPoolHighThreshold 


Description: This element represents the high threshold value of the 
number of public IP addresses in the address pool. 


Abstract Data Type: unsigned32 
Data Type Semantics: identifier 


Reference: See [RFC3022] for the definition of NAT. See [RFC3234] 
for the definition of middleboxes. 


6.1.13. addressPoolLowThreshold 
ElementID: 477 
Name: addressPoolLowThreshold 


Description: This element represents the low threshold value of the 
number of public IP addresses in the address pool. 
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Abstract Data Type: unsigned32 
Data Type Semantics: identifier 


Reference: See [RFC3022] for the definition of NAT. See [RFC3234] 
for the definition of middleboxes. 


6.1.14. addressPortMappingHighThreshold 
ElementID: 478 
Name: addressPortMappingHighThreshold 


Description: This element represents the high threshold value of the 
number of address and port mappings. 


Abstract Data Type: unsigned32 
Data Type Semantics: identifier 


Reference: See [RFC3022] for the definition of NAT. See [RFC3234] 
for the definition of middleboxes. 


6.1.15. addressPortMappingLowThreshold 
ElementID: 479 
Name: addressPortMappingLowThreshold 


Description: This element represents the low threshold value of the 
number of address and port mappings. 


Abstract Data Type: unsigned32 
Data Type Semantics: identifier 


Reference: See [RFC3022] for the definition of NAT. See [RFC3234] 
for the definition of middleboxes. 


6.1.16. addressPortMappingPerUserHighThreshold 
ElementID: 480 
Name: addressPortMappingPerUserHighThreshold 
Description: This element represents the high threshold value of the 


number of address and port mappings that a single user is allowed to 
create on a NAT device. 
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Abstract Data Type: unsigned32 
Data Type Semantics: identifier 


Reference: See [RFC3022] for the definition of NAT. See [RFC3234] 
for the definition of middleboxes. 


6.1.17. globalAddressMappingHighThreshold 
ElementID: 481 
Name: globalAddressMappingHighThreshold 


Description: This element represents the high threshold value of the 
number of address and port mappings that a single user is allowed to 
create on a NAT device in a paired address pooling behavior. 


Abstract Data Type: unsigned32 
Data Type Semantics: identifier 


Reference: See [RFC3022] for the definition of NAT. See [RFC3234] 
for the definition of middleboxes. See [RFC4787] for the definition 
of paired address pooling behavior. 


7. Security Considerations 


The security considerations listed in detail for IPFIX in [RFC7011] 
apply to this document as well. As described in [RFC7011], the 
messages exchanged between the NAT device and the Collector MUST be 
protected to provide confidentiality, integrity, and authenticity. 
Without those characteristics, the messages are subject to various 
kinds of attacks. These attacks are described in great detail in 
[RFC7011]. 


This document re-emphasizes the use of Transport Layer Security (TLS) 
or Datagram Transport Layer Security (DTLS) for exchanging the log 
messages between the NAT device and the Collector. The log events 
sent in cleartext can result in confidential data being exposed to 
attackers, who could then spoof log events based on the information 
in cleartext messages. Hence, the log events SHOULD NOT be sent in 
cleartext. 


The logging of NAT events can result in privacy concerns as a result 
of exporting information such as the source address and port 
information. The logging of destination information can also cause 
privacy concerns, but it has been well documented in [RFC6888]. A 
NAT device can choose to operate in various logging modes if it wants 
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to avoid logging of private information. The Collector that receives 
the information can also choose to mask the private information but 
generate reports based on abstract data. It is outside the scope of 
this document to address the implementation of logging modes for 
privacy considerations. 
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